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Abstract 

We address the design of distributed systems with synchronous 
dataflow programming languages. As modular design entails han- 
dling both architectural and functional modularity, our first contri- 
bution is to extend an existing synchronous dataflow programming 
language with primitives allowing the description of a distributed 
architecture and the localization of some expressions onto some 
processors. We also present a distributed semantics to formalize the 
distributed execution of synchronous programs. Our second contri- 
bution is to provide a type system, in order to infer the localization 
of non-annotated values by means of type inference and to ensure, 
at compilation time, the consistency of the distribution. Our third 
contribution is to provide a type-directed projection operation to 
obtain automatically, from a centralized typed program, the local 
program to be executed by each computing resource. The type sys- 
tem as well as the automatic distribution mechanism has been fully 
implemented in the compiler of an existing synchronous data-flow 
programming language. 

Categories and Subject Descriptors D.1.3 [Programming Tech- 
niques]: Concurrent Programming — Distributed programming; 
D.3.2 [Programming Languages]: Languages Classifications — 
Concurrent, distributed, and parallel languages 

General Terms Languages 

Keywords Synchronous programming, distribution, type systems, 
functional programming 

1. Motivations 

Synchronous programming languages |5 1 are frequently used in the 
industry for the design of real-time embedded systems. Such lan- 
guages define deterministic behaviors and lie on formal semantics, 
making them suitable for the design and implementation of safety 
critical systems. They are used, for example, in critical domains 
such as the automotive, avionics, or nuclear industry. 

Most of the systems designed with synchronous languages are 
centralized systems. The parallelism expressed in these languages 
is afunctional one, whose purpose is to ease the design process 
by providing ideal timing and concurrency constructs to the de- 
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signers. A synchronous program is then compiled into a sequential 
program emulating the parallel execution of the functional parallel 
branches. This sequential program is executed on a single comput- 
ing resource. Yet, most embedded systems are composed of several 
computing resources (named "locations"), for reasons such as per- 
formance, dedicated actuators or sensors drivers, or adaptivity of 
the locations to the tasks they are assigned to (e.g., pure computing 
tasks vs control tasks). We call this the execution parallelism. This 
paper addresses the problem of mapping the functional parallelism 
onto the execution one, in a modular way. We focus on distributed 
systems implemented as networks of deterministic processes com- 
municating with FIFOs. 

Fragments of a distributed system can be designed separately; 
but in complex and multifunctional embedded systems, functional- 
ities are frequently independent of the hardware architecture, im- 
plying conflicts between architectural and functional modularity. 
Thus, one functionality can use several locations and one location 
can be involved in several functionalities. As a result, programming 
each location separately compromises the modularity and is error- 
prone. This situation occurs within several industrial areas, such as 
automotive embedded systems, and software-defined radio 1151 . 

Our paper is organized as follows: Section[2]gives an overview 
of the context, and motivates our method through some examples 
and one application. Section [3] presents the semantics and the for- 
malization of the spatial type system. Section|4]presents the projec- 
tion operation, which is our third contribution. Finally, related work 
and discussion about the solution will be exposed in Section[5] 

2. Overview 

2.1 Distribution of Synchronous Dataflow Programs 

Synchronous dataflow languages, such as Lustre, Signal, or Lucid 
Synchrone |5|, manipulate infinite streams of values as primitive 
values: the notation 1 represents the infinite stream 1, 1, while 
int stands for the type of infinite streams of integers. For any 
stream x, we note Xi its ith value. In this context, functions (called 
nodes hereafter) are stream functions: e.g., int — >• int is the type 
of functions from integer streams to integer streams. Combinatorial 
functions are implicitly lifted to apply pointwise to their arguments: 
e.g., if x = (xi)ie in and y = (yj)ieiv are two integer streams, then 
(x + y) = (xi + ?/j)igjv. Moreover, we use a unitary delay, noted 
f by, such that (x fby y)j = a;o if i = and yi-i otherwise. 

Such a program is classically compiled into a single function /, 
which computes the values of outputs and updates the system's 
state, from the values of inputs and the current state. This function 
/ is then embedded inside a periodic execution loop. Our contribu- 
tion is to extend this classical compilation scheme to a distributed 
framework: the result of the compilation of a distributed system 
will consist of n functions /j, one for each location i, which will 
compute the values of outputs, communication channels, and lo- 



cal state, from the values of inputs, other incoming communication 
channels, and the current local state. 



2.2 Language-based Distribution 

We address functional distribution, not achieved for the sake of per- 
formance but because the system is intrinsically distributed. Distri- 
bution is driven by the fact that some functions have a meaning only 
at some specific locations and not at others. We can think, e.g., of 
a function returning the value of a physical sensor and which has 
to be executed where the sensor is. Therefore, locations will be de- 
fined by the functionalities they provide. 

Designing such distributed systems is non-trivial, because of 
problems such as the scheduling of communications or the type 
consistency of the communicated data. The usual method, using 
architecture languages like AADL [2], involves describing the sys- 
tem's architecture by partitioning it in subsystems. Each subsystem 
can then be defined separately, possibly with different languages. 
However, in the case of tightly dependent subsystems, where con- 
flicts between architectural and functional modularity can occur, 
it is less error-prone and more efficient to define the system as a 
whole, together with architectural annotations. Our first contribu- 
tion is to provide language primitives to allow the programmer to 
describe the architecture, and to express where some values are lo- 
cated, i.e., on which location some computations are performed. 

The architecture is described by the explicit declaration of the 
set of existing locations and the links between them. At this point, 
locations are symbolic: a location declaration introduces a sym- 
bolic name, which will then be used to express the fact that a stream 
is computed or available at this symbolic location. We define in 
Section 1431 a projection operation which produces, for each sym- 
bolic name, a single non-distributed synchronous program to be ex- 
ecuted at the physical location represented by this symbolic name. 

The syntax for declaring the physical location A is loc A. The 
existence of a communication link from A to B is declared by 
link A to B. Note that we distinguish communication links from 
communication channels, introduced in Section [3741 communica- 
tion links, specified by the primitive link, state the ability to com- 
municate from one location to another. In contrast, actual channels 
used by the distributed system are inferred by the type system. 

The statement e at A means that every value used in the expres- 
sion e (streams and nodes composing its subterms) will be located 
at A. The programmer does not need to express the localization of 
every value. Our second contribution is to provide a type and ef- 
fects system 1 19] whose double function is to check the validity of 
the localization expressed w.r.t. the architecture, and to infer the lo- 
calization of non-explicitly located values. For instance, the node 
f given below consists of two computations g and h, respectively 
located by the programmer on locations A and B, thanks to the at A 
and at B annotations, 
node f(x) = z with 
y = g(x) at A 
and z = h(y) at B; 

Communications are abstracted, and thus not expressed by the 
programmer, neither technically, nor concerning their place inside 
the code. The technical expression of communications is left to 
the further phase of integration on actual architecture: our method 
only deals with inferring the localization of these communications, 
and their coherence throughout the distributed code. We assume 
for now that communications can occur at any localization, and 
can concern any value entirely concealed within a location (i.e., 
not the distributed data structures, like distributed pairs). From a 
programmer's point of view, this choice is a compromise between 
no control at all (communications are possible everywhere) and 
absolute control (the programmer expresses every communication). 



2.3 A Spatial Type System for Automatic Distribution 

We place ourselves in a functional framework, where for the sake 
of modularity, functions can neither be inlined nor analyzed depen- 
dently of their calling context. We provide a special type system 
dedicated to the distributed execution of the program, as an analy- 
sis provided to the programmer to help him ensure the consistency 
of the distribution specification. We call it a spatial type system and, 
when clear from context, we shall simply refer to it as a type sys- 
tem. This spatial type system describes the localization of streams, 
and a type-directed approach is followed to achieve code distribu- 
tion. This also allows us to preserve higher-order features, hence 
allowing the expression of dynamic reconfiguration of nodes by 
application of other nodes as inputs. 

The other motivation for using a type system is to achieve 
type inference: in order not to force the programmer to specify 
everything (i.e., the localization of each stream), spatial types will 
be inferred from the available spatial annotations in the source. The 
spatial type system also checks the consistency of these annotations 
with the given architecture. Spatial consistency means, e.g., that 
applying a node located on a location to a stream located elsewhere 
is not correct. As we are in a functional context, spatial types will 
be inferred for each defined node modularly. 

A typed program is then automatically distributed by the com- 
piler, by extracting, for each declared location, one program strictly 
composed of computations to be performed on this location, as well 
as added communications from and to other locations in the form 
of added inputs and outputs. 

The spatial type of a stream is the location where this stream 
is located. In the case of a stream whose values are communicated 
via a channel from one location to another, its spatial type is a set: 
it is the set of locations where the stream will be available. The 
spatial type of a node / is written ti — (S)— > t , where ti and t 
are respectively the spatial types of f's inputs and outputs, and S 
is the set of locations involved in the computation of /. This set of 
locations can be larger than the union of ti and t 's sets of locations, 
since the computation of / can involve intermediary locations. 

2.4 Examples 

All the examples below assume the architecture declaration: 
loc A; loc B; link A to B; 

The first example is a sequence of three nodes f 1, f2 and f3, 
each assumed to be of spatial type V<5.c at 5 -{{5})— >■ c at 5. f 1 
and f 3 are localized by the programmer, respectively on A and B. 
f 2 is not explicitly localized, 
node g(x) = y3 with 

yl = fl(x) at A 
and y2 = f2(yl) 
and y3 = f3(y2) at B 
This node will be given the spatial type c at A —{{A, B})— > c at B. 
As the localization of computations has to be done modularly, a 
spatial type for f 2 will be given once, among the two possibili- 
ties c at A -{{A})-> c at A and c at B ~-{{B}}-^ c at B. In 
contrast, since there is no communication link from B to A, the 
following node will be rejected by the type system: 
node g'(x) = y3 with 
yl = fl(x) at B 
and y2 = f2(yl) 
and y3 = f3(y2) at A 
Furthermore, it can be noted here that node g cannot be used within 
a located declaration. The following node will be rejected by our 
type system: 

node g'(m,x) = y with 
y = g(m,x) at A 



The second example involves a higher-order node: the node h 
takes as input two nodes f and g, and an input x, and applies f to 
x at one location, and then g to the result of the first application 
at another location. This example shows also how a node can 
be defined with local locations for more modularity. These new 
locations are introduced as a list between [...], can then be used 
within the node. This higher-order node uses two location variables 
Si and 82 '■ 

node h [<5i,<52] (f,g,x) = z with 
y = f (x) at Si 
and z = g(y) at 82 
h receives then the spatial type: 

Va,/3,7.V<5i,<5 2 : {Si t>8 2 }. 

( (a at 81 -<{5i})-> fiat St) 
x(/3 at 8 2 -({(5 2 }H 7 at 8 2 ) 

x(aat<5i)J -({61,62})-+ 7 at S 2 

The set of constraints ({Si ><$2}) is inferred from the links required 
by the node. These constraints are resolved, with the actual archi- 
tecture, when this node is instantiated. A constraint S > 8' is re- 
solved, either by stating 8 — 8' — s, or with two locations s and 
s' such that there exists a communication link from s to s' in the 
local architecture. Thus, the node h can be instantiated in these two 
ways (assuming the existence of two nodes f and g, both of spatial 
type VS.c at S -({8})-¥ c at 8): 

yl = h (f at A,g at A,xl) 
and y2 = h (f at A,g at B,x2) 

We can observe than an arrow type appearing on the left of 
another arrow type cannot comprise more than one location. This 
is caused by the form taken by the distribution: since the projection 
operation on one node is performed on locations, and not sets of 
locations, we cannot handle effect variables, unlike other type and 
effect systems. 

2.5 Application 

As a concrete example, we consider the definition of a reception 
channel of a software radio. A software radio, or software-defined 
radio, is a radio in which components usually defined as hard- 
ware, e.g., demodulation or filter components, are defined as soft- 
ware [ 15]. This allows in particular the reconfiguration, possibly 
dynamic, of these components. 

Consider a reception channel composed of three main compo- 
nents: a pass-band filter allowing the selection of the carrier wave, 
a demodulator component, and a component allowing the analy- 
sis of the received signal, e.g., an error-correction function. For the 
sake of performance, these components are usually implemented 
on different architectural elements: the pass-band filter on a FPGA, 
the demodulator on a digital signal processor (DSP), and the error 
correction on a general-purpose processor (GPP). 

Each component of this reception channel could easily be de- 
fined separately. But in the case of software-defined radio, the sys- 
tem must support several functionalities |10|: each of these func- 
tionalities must be engineered separately, and then integrated to- 
gether. Then, there is a conflict between distribution and functional 
modularity issues. 

Let us study the case of a multichannel reception system that 
supports the two mobile standards GSM and UMTS: the former 
involves a filter for 1800 MHz frequencies, a GMSK demodulator, 
and a CRC / convolutional error correction module, while the 
latter involves a 2 GHz filter, a QPSK demodulator, and a CRC / 
convolutional / turbo codes error correction module. 

Figure Q] shows an implementation of this reception channel 
on a system composed of three hardware components: a FPGA 



dedicated to the execution of the two pass-band filters, a DSP 
for the demodulation functions, and a GPP for error-correction 
modules and for the control of the whole system, i.e., in this case, 
the switch between the two channels. This system has one input 
x, the radio signal from the antenna, y denotes the output signal 
of the system, i.e., the decoded and corrected information received 
by the channel. From this value, a function gsm_or_umts (noted g 
on Figure Q] for the sake of brevity), local at GPP, computes what 
channel will be used at next instant. In this figure, each location is 
graphically represented by a gray box. 



>| fflter_1800~~| » | dem.GMSlT] » | CRC/conv~ 



g(y)( ) ; 



;(y) 



filter_2000 J > | dem_QPSK~| > | CRC/turbo" 



Figure 1. Functional model of a multichannel software radio. 

In a classical context, designing this multichannel software ra- 
dio would be performed by separately programming each of the 
three hardware components, which raises two problems. Firstly, 
there is no guarantee that the components interact as specified: i.e., 
the 1800 filter with the GMSK demodulator, and so on. This re- 
quires the MUX function to be duplicated on the three computing 
resources, so as to guarantee the correctness of the system. This sit- 
uation compromises the modularity of the system. Secondly, each 
of the two channels corresponds to an independent software en- 
tity. Programming independently each hardware component leads 
to the separate design, at least from some point of the design flow, 
of closely related software components (e.g., filter and demodulator 
of the same channel). 

For the sake of modularity, this system would be better designed 
by considering the channels independently, and not the hardware 
components. This situation suggests adding primitives allowing to 
express the localization of streams directly in the language. Such 
primitives should allow the programming of software components 
independently of the architecture, handled as a separate concern. 
Thus, consistency analysis such as data typing could be performed 
on the global program: communication channels could be typed 
and the data consistency of the whole system could be checked. 
This way, inconsistencies due to serialisation could be detected at 
compilation time. 

The code below implements this multichannel software radio, 
with our extended language. The architecture consists of three 
locations, FPGA, DSP, and GPP, completely connected: 
node channeKf ilter,demod,crc,x) = y with 
f = filter(x) at FPGA 
and d = demod(f) at DSP 
and y = crc(d) at GPP 

node multichannel_sdr (x) = y with 
c = gsm_or_umts (y) at GPP in 

and 

if (true fby c) then 

y = channeKf ilter_1800,gmsk,conv,x) 
else 

y = channeKf ilter_2000,qpsk, turbo, x) 

This implementation strictly follows the architecture of the system 
described in Figure [T] It shows the declaration of three symbolic 
locations (FPGA, DSP, and GPP). We assume that all filter, demod- 
ulation, and correction functions are local ones, i.e., they are of 



spatial type \/S.c at <5 — ({5})— > c at 5. Since the conditional con- 
struct comprises declarations that have to be executed on the set of 
locations {FPGA, DSP, GPP}, c is thus inferred to be communicated 
to these locations. The conditional if/then/else is evaluated with 
the value of c at the previous instant. The distribution of this exam- 
ple will put a copy of this if /then/else on these three locations. 
Finally, the expression true f by c will be computed at GPP, since 
the result of this expression has to be communicated to the three lo- 
cations where the conditional construct will be duplicated. 

By the same reasoning, we can infer that the spatial type of x is 
FPGA, and the one of y is GPP. As a result, the spatial type of the 
node multichannel_sdr is: 

(c at FPGA) -({FPGA, DSP, GPP})-i> (c at GPP) 

3. Formalization 

We first define a synchronous dataflow core language (Section [3~ll . 
and give its centralized semantics (Section [3.2b and its distributed 
semantics (Section l3.3b . The centralized semantics is considered 
to be the reference semantics and we only consider programs that 
react w.r.t. this semantics. Programs that do not react (e.g., for 
typing or causality reasons) are assumed to be rejected by other 
means |9|. The distributed semantics allows us to give a meaning 
to location annotations. A spatial type system is then presented 
(Section [3.4b . It is used to both reject programs which cannot be 
distributed and to annotate every expression from the source code 
with explicit locations. 

3.1 The Core Language Syntax 

P ::= A;d;D 

A ::= A; A | loc A | link A to A 

a ::= S \ A 

d ::= node f[8i, . . . , S n ](p) = e with. D \ d;d 

D ::= p = e | p — x(e) | D and D | if e then D else D 

p ■■■= p,p \ x 

e ::= i \ x | (e, e) | op(e, e) | e fby e | e at s 

A program is made of an architecture description (.4), a se- 
quence of node definitions (d) and a main set of equations (D). 
An architecture description is a set of declarations of locations 
(loc A) or links (link A to A) which state the existence of a 
communication link from one location to another. A location s is 
either a location variable S, or a location constant A. A node defi- 
nition is composed of an expression and a set of equations. A set of 
local locations [Si, . . . , S n } can be associated as location param- 
eters of a node definition (node f[Si, ■ ■ ■ , 8 n ](p) = e with D). 
Definitions D define patterns of variables p, and are either single 
equations (p = e), definitions naming the result of an application 
(p = x(e)), parallel declarations (D and D), or alternative declara- 
tions (if e then D else D). An expression e may be an immediate 
value (i), a variable (x), a pair construction (e, e ; pair destruction 
can be performed by pattern definitions), a binary combinatorial 
operation (op(e, e), where op can be (+), (— ),. . . ), an initialized 
delay (e fby e), or an expression annotated with an explicit location 
s (e at s). 

3.2 The Centralized Synchronous Semantics 

The purpose of the centralized semantics is to serve as a reference 
semantics. This semantics does not take into account distribution 
primitives. We first introduce auxiliary definitions. A value is either 
an immediate constant (i), a pair or a function. 



v :\— i | (v, v) 
R ::= [vi/xi, 
S ::= R1.R2 ■ 



Xx.e with D 

. . , Vn/x n ] S.t. Vi 7^ j, Xi =fi Xj 



A reaction environment R associates values to names and assumes 
that names are pairwise distinct. S denotes a sequence of reaction 
environments. 

Given a sequence d of node definitions node fi[5i](xi) = 
d with Di, an initial global environment Rd is defined, holding 
A-values of each fi . This initial environment will be given as input 
of the main program. 

R d = [Ax-i.ei with £>i//i, ■ ■ -, Ax„.e„ with D n /f n ] 

The synchronous centralized semantics is defined by means of 
two reaction predicates, i? h ei A 62 states that in the reaction 
environment R, the expression ei emits the value v and rewrites 

into the new expression 62. The predicate 7? h D\ ^-s> D2 states 
that in the reaction environment R, the declaration Di defines the 
reaction environment R' and rewrites into D2 . The centralized ex- 
ecution of a program P is denoted S, h P : S„, meaning that 
under a sequence of input environments Si = R1.R2 ■ ■ •, the pro- 
gram P — A;d;D produces a sequence of output environments 
So = R'i-R' 2 . . . such that: 

Rd,Ri,R h D D' Sr h A;d;D' : S 
Ri.Si h A;d;D : R .S 
The rules for the reaction predicates are given in Figure[2] 



(IMM) R h . 



(Fby) 



: A i (Inst) r, [ v /x] hAi 

R h e± — ► e 1 xthej — > e 2 
R \- ei fby e 2 —A V2 fby e' 2 



(OP) 



R h ei — ^ e'i R. h e 2 —A e' 2 i = op(ii,i 2 ) 
R h op(ei,e 2 ) -V op(ei,e 2 ) 



(Pair) 



v 2 I 
e 2 



Rh (ei,e 2 ) ► (e 1 ,e 2 ) 



(AT) 



ijheat sAe' at s 



(DEF) ■ 



Rh e > e 



(APP) 



Rh (xj, . . . ,x n ) = e > (x 1 , . . . ,x n ) = e 

R(f) = \p.e with D R h p' = e and p = e' and D -^U D' 
Rhp' = /(e') D' 



(And) 



R, R 2 h Di D[ R, Ri h D 2 ^> D' 2 
R h £>i and D 2 Rl ' R ' 2 ) D[ and D 2 



(IF-1) 



Rh e 



R h Di D[ 



Rh if e then D\ else D 2 if e' then Dj else D 2 



(IF-2) ■ 



_ . false / 

Rh e > e 



Rh D 2 ^U D' 2 



R h if e then Z?i else D 2 — — > if e then Z?i else D 2 



Figure 2. Centralized synchronous semantics. 

An immediate value emits itself and rewrites to itself (rule 
IMM). A variable emits its current value as it is present in the reac- 
tion environment (rule INST). An initialized delay ei fby e 2 emits 
the first value of ei, then the previous value of e 2 (rule Fby). An 



operation is performed pointwisely on immediate values (rule Op). 
Pair construction follow classical rules (rule PAIR). Locations are 
not taken into account here (rule At): annotations added by the pro- 
grammer do not alter the centralized semantics of the program (i.e., 
its functionality). An equation p — e emits the reaction environ- 
ment defining the variables contained inp (rule Def). A sequential 
function application is replaced by its body and argument definition 
(rule App). Parallel equations are mutually recursive (rule And). A 
conditional statement executes its first branch if its condition is true 
(rule lF-1) and its second branch otherwise (rule lF-2). 

3.3 The Distributed Synchronous Semantics 

The distributed semantics also operates on a program P = A;d;D, 
but takes into account the architecture description and the explicit 
locations. However, it remains a synchronous semantics in the 
sense that the desynchronization due to the insertion of commu- 
nications is not accounted for. It defines a spatialized execution: 
the values v emitted by expressions are now distributed values, 
i.e., they are annotated with location information stating how these 
values are distributed on the architecture: 



v 

Iv 

R 

S 

G 



:= Iv at A | (v, v) | AS.Xx.e with D 
:= i | (Iv, Iv) 

:= [vi/xi, . . . , v n /Xn] s.t. Vi / j,Xi / Xj 
:= R1.R2.... 
■■= (S,C) 

A distributed value v is either a local value Iv, localized on the 
site A (Iv at A), a distributed pair (v, v), or a node. A sequence 
of location parameters 5 is associated to nodes. A local value is 
either an immediate value i, or a local pair (Iv, Iv). R denotes a 
distributed reaction environment, and S a sequence of distributed 
environments. G denotes an architectural graphs composed of a set 
of locations 5, and a set of communcation links £ C 5 x 5. 

Several values can represent the same distributed value: 

(Ivi, IV2) at A — (Ivi at A, lv2 at A) 

V\ = V\ V2 = v' 2 



(vi,v 2 ) = (v[,v 2 ) 

These equalities mean that a local pair (1,2), localized on the 
site A, can indifferently be denoted by the distributed values 
(1,2) at A or (1 at A, 2 at A). A distributed pair can be, for 
example, the pair (1 at A, 2 at B) : the first compound is located 
on A, and the second on B. 

The operator loc(-) gathers the set of locations from a dis- 
tributed value: 

loc(i at s) — {s} 

loc((«i, 1)2) at s) — loc(-Oi) U 100(7)2) 

The operator | • | erases annotations from a distributed value to 
get a centralized value, and extends straightforwardly to reaction 
environments: 



\l at s 



[(«!: 



V2) at s\ = (|6i|, \v 2 \) 



The distributed semantics is defined by means of two predicates 

- 1 V 

refined from their centralized versions. R lh ei — > e2 states that 
in the distributed reaction environment R, the expression ei emits 
the distributed value v and rewrites into C2- t represents the set 
of locations involved in the computation of 11. The predicate for 
declarations is defined as well. 

We denote by 5 the set of declared constant locations, and 
by £ C 5x5 the set of declared communication links. The 
relation £ defines the ability to communicate, and not the actual 
existence of communication channels, which will be inferred by 
the refined version of the type system. G denotes an architecture 



graph, composed of a set of locations 5, and a set of links £ 
between these locations. An architecture description A defines an 
architecture graph G: the notation G h A : G' means that given 
the architecture graph G, A defines the new architecture graph G' . 
The rules ARCH, Def-Loc and DEF-LlNK define this predicate: 



(Arch) 



{S,C)\-Ai : (Si,d) {S 1 ,C 1 )\-A 2 ■■ (5 2 , £2) 
(S,C)\-Ai;Ai : (S 2 ,C 2 ) 

(Def-Loc) (5, C) h loc A : (5 U {A}, C) 



(Def-Link) 



A U A 2 G S 



(S, C) h link A x to A 2 : (S, C U {Ai i-> A 2 }) 



For clarity, we assume that the architecture graph G is global for 
subsequent semantic rules. The annotated execution of a program 
P is Si lh P : S , meaning that under a sequence of input envi- 
ronments Si — R1.R2 ■ ■ ■, the program P — A;d;D produces a 
sequence of output environments So — R\.R 2 ■ ■ 

(0,0)h^:G Rd,Rj, Ro lh D D' Sj lh A;d;D' : S 
Ri.Si \^A;d;D : R .S 

where Rd is defined from the sequence of node definitions d — 
node fi[Si](xi) = ei with Di as: 

Rd = [A5i.Axi.ei withl>i//i, . . . ,A5„.Xx n .e n withD n // n ] 

~ 1 v - 1 Ft' 

The rules for the predicates R lh e\ — > e2 and R lh D\ — > D2 
are given in Figure[5] An immediate value can be emitted anywhere 
(rule Imm). Rule INST defines the instantiation. A distributed value 
can be communicated from location s to location s' if there exists a 
communication link from s to s' (rule COMM). A binary operation 
can be performed only on immediate values located on the same 
location A; the result is located on A as well (rule Op). An an- 
notated expression must involve at most the location stated for its 
computation (rule At). An application involves choosing a set of 
constant locations, and replacing location parameters by these lo- 
cations in the expression and the declaration (rule App). The other 
rules state that the computation of a statement involves the union 
of the locations involved for the computation of its compounds. 

Lemma Q] states that if a program reacts with the distributed 
semantics, then it reacts with the centralized one and produces the 
same values. 

- ( r' 

Lemma 1. For all D,D',R,R', if R lh D — 
exists R, R' such that R = \R\, Rf = \R'\ and Rh D 



D', then there 
^ D'. 



3.4 Spatial Types 

For the sake of clarity, we first present a simplified version of the 
type system. For projection, we refine this first version to take 
communication channels into account (Section|4j. 
The syntax of spatial type expressions is: 



a 
t 

tc 
I 
s 
H 
C 



:— Vai, . . . , a n .V(5i, . . . , 5 n : C.t 
:= t -{t)-^ t I t X t I teat s 
:= c I a I tc — > tc I tc x tc 
:= {si, ...,s n } 
:= 6 I A 

:= H at A I [xi : ai, . . . , x n : a n ] 
:= {si > s'i, ...,s n t>s'„} 



H is the spatial typing environments. H at A denotes a located 
environment, i.e., a typing environment from which every spatial 
type will be forced to represent a value entirely located on A. 



(IMM) 

„ t 



(COMM) 



A ii av at s / . /. 

if, h e > e (s, s ) G £ 

g/UjV} di,[ S '/s] at s' , 

H h e > e 



(FBY) 



R Ih ei ei if Ih e 2 ei, 
R lh ei fby C2 — > \V2\ fby e2 



(Inst) 

loc(-s) 6 
i?, [fi/x] lh a; — > 

(OP) 

An 1 ii at A / Am 2 ^2 at A , . . . . * 

it Ih ei > ej^ it Ih e 2 > e 2 I = op(ii,i 2 ) 

- *i u ^2 • at A ' ' 

R Ih op(ei,e 2 ) >op(e 1 ,e 2 ) 



(Pair) 



R Ih ei 



d^l at s i / 



> e t i? Ih e2 



i>2 at S2 / 



ft ii / \ (dwi «t »i,d«2 at sa) «t siUsa ,/ 

R Ih (e\,e 2 ) ► (e 1 ,e 2 ) 



{«} 



(AT) 



(DEF) 



{«} 



it Ih e > e 



R Ih (xi, . . . ,:r n ) = e — - — '—>■ (xi, ■ . ■ ,x n ) = e' 



(APP) 



R(f) = A<5i , . . . , <5 n .Ap.e with flats {si, . . . , s n } C S 
R Ih p' = e[s/<5] and p = e' and D[s/5] D' 

H Ih p' = /(e') D' 



R,R 2 ^D 1 ^D' 1 R,R 1 fD 2 -^D' 2 
R Ih Di and D 2 2 > D[ and D 2 



«2, 



(And) 



(IF-1) 



R Ih e " ue " s > e' RlhDi-^Di Vs'e^',s> S ' 
i? Ih if e then Di else D 2 — + if e' then Di else D 2 



(IF-2) 



g Ih e false at "> e' R\^D 2 ^Ud' 2 Wee',s>s' 
- lut -' ft' 

R Ih if e then D\ else D 2 — -> if e then Di else D 2 



Figure 3. Distributed synchronous semantics. 

We distinguish spatial type schemes (a), which can be quanti- 
fied, from simple spatial types (i). A set of constraints C can be as- 
sociated to quantification of location variables (V<5i , . . . , S n ■ C'.t). 
We note V«5i, . . . ,S n .t the scheme V<5i, . . . , S„ : %.t. A simple spa- 
tial type can be either a node type (t — (£)— > t), a pair type (t x t), 
or a located type (tc at s). A located type can be either a stream 
type (c, such as boolean, integer, etc.), a type variable (a), a local 
function (tc ~ > tc), or a local pair type (tc x tc). I denotes sets of 
locations. A location is either a location variable S, or a location A. 

C is a set of constraints between locations. A constraint si > s 2 
means that either si = s 2 , or there exists a communication link 
from Si to s 2 . Conversely, a declaration of communications links 
£ leads to the set of constraints constr(£) = {s t> s'\(s, s') £ £}. 

A value of spatial type tc at s is a value located on s. A value of 
spatial type ti —{£)-¥ t 2 is a node whose input is of spatial type ti, 
whose output is of spatial type ti, and whose computation involves 



the set of locations £. The following equalities stand: 

(tci x iC2) at s = (tci at s) x (iC2 at s) 
(ici — > tc 2 ) at s = (tci at s) —{{s}}-^ (tci at s) 



t\ — t[ t 2 = t' 2 



t\ t 2 — t' 2 



(h x t 2 ) = (t; x t' 2 ) ti 1 2 = t[ -{£y^ f 2 

The instantiation mechanism ensures the localization of a type 
instantiated from a located environment: 

(t[tci/ai, . . . ,tcn/a n , s/5],C[s 1 /8 1 , s m /8 m )) 

< Vai . . . Q n V5l ... (5m : C.t 

(tc at s, C) < (H at s)(x) <^ (tc at s, C) < H(x) 
We note respectively FLV(i) and FTV(f) the set of free loca- 
tion variables and free type variables of the type t. FLV and FTV 
are straightforwardly extended to typing environments. 

A set of constraints C is compatible with a set of communica- 
tion links £, noted £ \= C, iff s > s' G C A s s' => (s, s') G £. 

Before presenting our spatial type system, we introduce the 
following notations: 

• For a program P, the notation \- P : t means that the program 
P is of spatial type t. 

• For declarations (resp. expressions), the notation H\G h D : 
H 1 jl (resp. H\G h e : t/l) means that, in the spatial type 
environment H and the architecture graph G, the declaration 
D (resp. the expression e) defines a new environment H' 
(resp. is of spatial type t), and its computation involves the 
set of locations £. 

The function locations(-) gives the set of locations involved in 
the spatial type given as argument. It is defined as: 

locations(ii x t 2 ) = locations(ii) U locations^) 

locations(ii ti) = I 

locations(ic at s) = {s} 

The top-level declaration of a program is typed from the initial 
environment Ho, defined as: 



H = 



• fby • : Va.VS.a at S x a at S -{{S}}-¥ a at S, 
(+) : V<5.c at S x c at S -({<5}H> c at S, . . . 



Our spatial type system is formally defined by the inference 
rules shown in Figure [4] Typing a program involves building an 
architecture graph from the architecture description, and then using 
it to type the nodes and the main declarations (rule PROG). 

An immediate value can be used on any location (rule IMM). 
Type schemes can be instantiated (rule INST). Typing a pair in- 
volves stating that this pair has to be evaluated on the union of the 
sets of locations on which each member of the pair has to be eval- 
uated (rule PAIR). Typing a located expression (e at A) involves 
building a located typing environment (rule At). Communications 
are expressed as subtyping (rule COMM). 

The spatial type of a node consists of the spatial types of its 
inputs, the computed expression, and the set of locations involved 
in this computation (rule NODE). The type of a node is generalized 
w.r.t. the set of locations and links introduced by this architecture. 

Typing an equation x = e involves building a singleton typing 
environment (rule DEF). Rule APP states that an application must 
be evaluated on the union of the set of locations where the node 
/ and its argument e must be evaluated, and the set of locations 
l\ involved in the computation of the node /. Parallel declarations 
involve, for their computations, the union of the sets and of loca- 
tions involved in the computation of their compounds (rule And). 
Finally, typing an if/then/else declaration involves locating the 
condition expression on a location s, and adding constraints that ev- 
ery location involved in declarations Di and D 2 must be accessible 
from s (rule If). 



(Prog) 



,®)hA:G H \G\- d: H/£ H, -ffi|G H D : H%/t' 
h A;d;D : Hi 

(t,C)<(H(x)) C\=C 



(IMM) 

H\G\- i : cat s/{s} 



(Inst) 



(Pair) 



(Def) 



H\(S,C) h x : t/ locations (t) 

H\Ghei:ti/£i H\G h e 2 : t 2 /l 2 
H\G h (ei,e 2 ) : ti x t 2 /<iU< 2 

ff|G h e: ti X ... X t„/£ 
#|G h(n i„) = e: \tljxu- ■ -,t„/x n }/e 

Ha.ts\(S,C)\-e:t/l seS 



(AT) 



(COMM) 



H\(S,C) h ea.ts:t/£ 

H\{S,C) h e : teat s/l C\=s>s' 
H\{S,C) I- e : teat s'/IU{s'} 



(Node) 

_fl>i : ti,Hi|(5',£'> h D : Hi/h 
H,Xi :ti,Hi\(S',C') he:t/f 2 S' = S U {61, . . . , S p } 
C CCU{{6 1 ,...,8 P } xS)U(Sx {Sx,...,5 p }) 

{ai 0™} = FTV(i) - FTV(-ff) C = constr(£' \ C) 

a = Vai, . . . ,a m .VS lt . . .,S p : G.fti X . . ■ X t w ) ~{h U4)-» * 
_H"|Ghnode/[5i,...,<5 p ](a:i,...,x n ) = e with D : \pJJ\Jti U £ 2 



(APP) 



ff|G h / : t -(^lH- (*i x ... x 4)/^ 2 H\G h e : t/£ 3 
H|Gh (n i„) = /(e) : [i' 1 /n,...,4/x„]/<iUf 2 Uf; 



(And) 



(If) 



H\G h Di : H\/l\ H\G h D 2 : H2/I2 
HjGh Di andD 2 : H 1 ,H 2 /£ 1 <J i 2 

_ff|G he:cats/< H[G H Di : if'/^i 

i?|G h D 2 : H'/fa ^ 1= {s>s'\s' e uf 2 } 

H|G Fife then Di else _D 2 : WJl UfiUf 2 



Figure 4. Spatial type system. 

We denote by v : t the fact that the distributed value v has 
spatial type t: 



Iv at s : c at s 



v 2 : *2 



(vi,«2) :tiXt 2 
We denote by R : H the type compatibility between _R and ff : 

R : H ^> Vx g dom(A), x £ dom(i?) 

A 3(t, C) s.t. (t, C) < H(x) A R(x) : t 

Theorem Q] states that if a program reacts with the centralized 
semantics, and is accepted by our type system, then there exists a 
spatialized execution such that the distributed values of this execu- 
tion are equal to the centralized ones. The types are preserved by 
this spatial execution. The proof is omitted for lack of space. 
Theorem 1 (Soundness). For all D,D',H,H',R,R',G, if H\G h 

D : H'/l and R h D 
ft! 



R\V D 



D', then there exists R, R' such that 
D' R:H,R': H', \R\ = Rand \R'\ = R'. 



4. Distribution 
4.1 Principle 

Once programs have been typed, every expression is annotated with 
a location that specifies where it has to be computed. Communica- 



tions are inserted when a value is produced at a location and used 
at another. From this typed program, the compiler produces several 
new programs — one for every location s — erasing the code that 
is not necessary at this location s. The run-time we have chosen 
is a classical one for globally asynchronous locally synchronous 
(GALS) systems: communications are done through FIFOs. 

We show below the result of the projection of the node f of 
Section lZ2l on A and B, noted respectively f _A and f _B. The distri- 
bution of this node will involve adding a communication between 
these two computations. This communication will take the form of 
an additional output on f _A (named here c_y, holding the value y 
computed on A and used on B), together with an additional input on 
f _B. Original inputs and outputs are not suppressed: ^denotes an 
irrelevant value which will not be used on the current location. It is 
used here to replace the output z, whose computation is suppressed 
at A. 

node f_A(x) = (_L,c_y) with 



node f_B(x,c_y) 
z = h(c_y) 



z with 



The semantically equivalent distributed system is then obtained by 
connecting the input and output c_y, holding the communicated 
value y. The program below shows the distributed execution, using 
a FIFO materialized by send/receive primitives, of the result of 
the projection of the program y = f (x) . 



(y_A,c_y) 
send(c_y) 



f_A(x): 



receive(c_y) ; 
y_B = f_B(±,c_y) 



4.2 Example 

The result of the projection of the two nodes of the Section [J 
on the location DSP is given on Figure [5] The projection of the 
channel node shows that the node applications of filter and crc 
have been removed, and that a new input cl (holding the value off) 
and a new output c2 (holding the value of d) have been added. This 
implies the addition, on the projection of the multichannel_sdr 
node, of two new inputs (c2 and c3) and two new outputs (c4 
and c5), one for each channel instance. The new input cl of the 
projected multichannel_sdr node holds the value c. 



node channel (filter , demod , crc , x , cl) 
d = demod (cl) 
and c2 = d 



(_L,c2) with 



node multichannel_sdr(x,s,cl,c2,c3) = (^,c4,c5) 
if cl then 

(y,c4) = channel (_L ,gmsk, _L , _L , c2) 
else 

(y,c5) = channel (_L ,qpsk, _L , _L , c3) 

Figure 5. Result of the projection on DSP 
4.3 Projection 

We will now define a type-directed operation of projection of an 
expression on a location A. This operation is defined separately, as 
it has to be performed on an already annotated program: links be- 
tween values of each projected program are defined by the channels 
inferred by the type system. The projection will use a refined ver- 
sion of the type system, allowing the inference of communication 
channels. 

A channel is a location pair associated with a name, noted 
Ai A 2 : c is the name of the channel, Ai its source location, and 
A 2 its destination location. The set of channel names is ordered by 
<, so as to keep consistency of inputs and outputs added, from the 



node definition to node instances. T denotes sequences of channels. 
The concatenation of two sequences of channels, noted T\,T 2 , is 
defined iff channel names in T\ and T 2 are disjoint. We denote by 
e the empty sequence. 

We note dom(T) the set of channel names of T. T' T 
means that the sequences T and T" are equal, modulo channel 
renaming. This renaming allows the multiple instanciations of node 
comprising communications. 

T' = T T' — T[ci/ci,...,t4/cn] where {ci,...,c«} = dom(T) 
The projection of a declaration D on a location A is noted 
H\G h D : H'/l/T D', and results in a new declaration D', 
containing only the computations to be performed on A. The pro- 
jection of an expression e, of spatial type t, on a location A, is noted 

H\G h e : t/i/T e'/D, and results in a new expression e', as 
well as a declaration D, containing channels outputs to be defined. 
A channel named c in an environment channel will be introduced 
as the variable c as input or output of the target program, c assumed 
to be of different name space than other variables of the source pro- 
gram. 

We denote by e the empty declaration, and by _L a value which 
will never be used (i.e., void). For any declaration D, D and e = 
e and D — D. For any expression e, we have (_L e) = (e J_) = _!_. 

Also, we note T J A (resp. T \, A) the set of channels with 
origin (resp. destination) A: 

'\A\ A- A 2 ], (T t A) HAi=A 
(T t A) else, 



AA a ],T)t4 



M = 
([ill A Aa],T)lA 



[AiA-A],(TlA) ifA 2 =A 
(T I A) else. 



The projection rules are given in Figures [6] and [7] Channels are 
used at communication points. If an expression e is sent from A to 
A' through the channel A A A', then: 

• for the projection on A, the communication involves sending 
a value: the resulting expression is void, and we add the 
definition of the channel c as the result of the projection of 
e on A (rule Comm-P-From); 

• for the projection on A', the communication involves receiv- 
ing a value: the resulting expression is the channel holding 
this value (rule COMM-P-To). 

Finally, if A does not appear in the set of locations involved in 
its computation, then the expression can be suppressed on A (rule 
SUPPR-P). Projections of a pair consist in the projection of its 
compounds (rule PAIR-P). 

The projection of a located declaration and parallel declarations 
involves the projection of its compound (rules At-P and And-P). 
The projections of applications and node definitions involve adding 
to the inputs and outputs of the node, the channels used by this 
node (rules APP-P and NODE-P). Nodes with local architecture 
are assumed to be inlined. The relevance of the name order appears 
here, as the order of the added inputs and outputs must be consistent 
with every instances of these nodes, and for every projection. 

Projection of a conditional is divided in two rules: one for 
the projection on a location where the conditional expression is 
computed: this first rule shows the definition of every channel 
needed to send this value to other locations where the conditional 
will be evaluated (rule If-P-From); and one for the projection on 
a location where the conditional expression has to be received: this 
expression is then replaced by the name of the channel holding this 
value (rule If-P-To). 



(IMM-P) 

H\G hi: cat s/{s}/e =4> i/e 



(INST-P) 

(t, G) < (H(x)) C\=C 

H\G h x : t/i/e x A /e 

(SUPPR-P) 



A 1 



(At-P) 

H at A\G h D : H'/i/T =4- D' 
H\G h D at A : H'/l/T £>' H\G h e : t/i/T =^> _L/e 

(Comm-P-From) 

H\ (5, C) h e : tc at A/t/T ^ e'/D C \= A > s' 
H\(S,C) h e : teat s' / l\J {s 1 } /T, [A A s'} _!_/£> and c n = e' 



(COMM-P-TO) 



H\(S,C) h e : teat s/l/T =^> e'/D C |= s > A' 
H\(S,C) he: teat A'/tU{A'}/T, [s A A'] =^> c n /D 
(Pair-P) 

H\G h ex : h/h/Ti =4> e' 1 /D 1 H\G h e 2 : t 2 /£ 2 /T 2 =A e' 2 /D 2 
H\G h ei,ea : h X t 2 /ti l>e 2 /T 1 ,T 2 ei,e 2 /£)i and D 2 



(Def-P) 



(App-P) 



H|G h e : ti x . . . x t n /i/T e'/D 
H\G h ( Xl ,...,x n ) = e: \hjx77- ■ ■ , t n /x n ]/£/T 
=> (xia, ■ ■ ■ ,x n A) = e andD 



H\G\-f:t -(ii/ny* (ti x ... x O/I2/T2 ^ /'/Si 
H|G h e : t/^s/Ts ^ e'/D 2 T{ S Ti 
T{t^=[^3-Ai,...,A c ^ A ro ] 

T{ 4. A = [Ai A, . . . , A; % A] 
H|G I- (xi, . . . ,x n ) = /(e) : [t 2 /x]/hUl 2 Vll 3 /Tl,T2,T z 
^> (x 1A , . . .,x nA ,ci, Cm) = f'(e',c[, . .. ,c' p ) and Di and D 2 

(AND-P) 

H\G V- Di : Hx/lx/Tx =4> Dj g|G h D 2 : H 2 /i 2 /T 2 ^ £> 2 
_ff|G h £>i andD 2 : H 1 ,H 2 /£ 1 Ufe/Ti,T 2 ^ Di and D 2 



Figure 6. Rules for the projection operation (I). 



The global meaning of a distributed program is then defined by 
the parallelization of its projected declarations. 

We note <S = {Ai, . . . , A n } the set of defined constant loca- 
tions where the source declarations are projected. The global mean- 
ing of a declaration D, projected on the locations <S, is defined by: 

Di and ... and D n where Vi, H\G h D : H'/l/T ^> Di 

In order to relate a target program with its source, we define a 
relation on values, denoted ■ =4'. ■, such that v v means that the 
value v', emitted from an expression of type t, represents the value 
v at the location A. We have: 



A^ A Vi =4 tl vi v 2 =$ t2 v 2 



I jA 1 , A 1 1 1 \ ,A { \ 

V ^tatAV ±=^ tatA /« (Vl,V 2 ) =4 tlXt2 (Vl,V 2 ) 



typing environment H: 

R 4h RpiffVx G dom(i?),VA G S,R(x) R v {x A 



Theorem [2] states that the projection operation is correct, i.e., 
the projection of a source program D into Di (for every location 
Ai) defines a new target program Di and . . . and D n , which is 
semantically equivalent, taking into account spatial types' values, 
with the source declaration D. The proof is omitted for lack of 
space. 

Theorem 2 (Soundness of the declarations projection). For all H, 

H', D, D', £, T, Di, R, R', if R h D —¥ D', H\G h D : 

H'/l/T and\ti,H\G h D : H'/£/T D it then there exists 
R p , R' p , Dp, D' p such that D p = D± and . . . and D n , R =4h Rp, 

R p h Dp — ^> D' p , and R' =4 H i R' p . 

5. Discussion 

5.1 Implementation 

The spatial type system presented in Section [3~4l relies on a subtyp- 
ing mechanism. It corresponds to the case where communications 
can occur anywhere in the code. This situation raises two prob- 
lems. Firstly, the implementation of type systems with subtyping 
mechanism is costly: usual algorithms rely on the systematic ap- 
plication of the subtyping rule. Secondly, this choice leads to a sit- 
uation where the programmer has no control over where the com- 
munications can occur. These problems, though orthogonal, can be 
addressed together: giving some control to the programmer means 
restricting the points where subtyping can be applied. We refine our 
type system in order to address these two problems. 

We restrain communicated values to be variables introduced by 
equations (x = e). Thus, in the program of Section \22\ only y 
and z can be communicated from one location to another. Then, we 
can use a generalization mechanism to infer communication con- 
straints, instead of inferring them by subtyping. This corresponds 
to restricting the subtyping mechanism to instantiation points. 

This refined type system, as well as the projection operation 
presented in Section [4] have been implemented in the Lucid Syn- 
chrone compiler 1 1 1. The independence of the method w.r.t. other 
analysis allowed this implementation to be quite modular, implying 
very few modifications within the rest of the compiler. The imple- 
mentation consists to generate distribution constraints, which are 
resolved modularly for each node. We implemented a naive resolu- 
tion algorithm, which can easily be replaced by any existing distri- 
bution algorithm, taking into account efficiency issues (for exam- 
ple, the AAA method of SynDex [ 18 1). This implementation has 
been tested on the software-defined radio example, which is in its 
actual size composed of 150 lines of code, spread out into 25 Lucid 
Synchrone nodes. We have tested our automatic distribution algo- 
rithm on a benchmark suite composed of programs of few hundred 
of lines from the current Lucid Synchrone release. This point is 
a good indication of the flexibility of the extension proposed, al- 
lowing the distribution of programs not primarily designed with 
distribution in mind. The scalability of this method is a direct out- 
come of the use of a type system aiming at modular distribution; it 
has been also applied on an ad hoc example composed of 10 Lucid 
Synchrone nodes, comprising each 60 equations. 

5.2 Related Work 

Various solutions have emerged in order to use synchronous lan- 
guages for the design of distributed systems. Some of them operate 
on a compiled model of the program, by "coloring" atomic instruc- 
tions with localization information, inferred from input and output 
locations [8|. The whole program is first compiled into an interme- 
diate sequential format, on which the distribution is then applied. 
This format consists of a sequence of atomic instructions, repre- 
senting one computation step of new values carried on each stream. 
Then, the distribution involves placing each instruction onto one or 



several locations, taking into account the consistency of the con- 
trol flow on each location. Another approach is to directly annotate 
the source program with locations, so as to define the localization 
of each variable of the program: the distribution is then performed 
with regard to these annotations. This approach has been applied 
to Signal |3] as well as Lustre |7|. In both cases, the soundness of 
the distribution algorithm has been proved 151 1141 . meaning that the 
combined behavior of the distributed fragments has the same func- 
tional and temporal semantics as the initial centralized program. 
The originality of our method resides in the fact that we use a spa- 
tial type system to check the consistency of the distribution specifi- 
cations inserted by the programmer, and that we perform modular 
distribution, allowing the expression of higher-order features, ap- 
plied for instance to dynamic reconfiguration of nodes by applica- 
tion of other nodes as inputs. Since a Kahn semantics 1 11] can be 
given to our language, the semantic equivalence between the source 
program and the synchronous product of the fragments resulting 
from the projection is sufficient to describe an asynchronous dis- 
tribution. While the language presented has higher-order features, 
this method can easily be applied to other language with compara- 
ble semantics such as Lustre. In contrast, more general frameworks 
such as Signal cannot be addressed here for this reason. 

Several approaches have been considered to solve the problem 
of data consistency of distributed programs. A translation operation 
is presented in 1161 , as well as an effect type system, in order to au- 
tomatically obtain a multi-tier application from an annotated source 
program. Our proposition differs by the fact that our type system 
is not only a specification, but also consists in what the authors 
called "location analysis", thus allowing us to perform this analysis 
in a modular way, and on a program comprising higher-order fea- 
tures. This last approach, as well as our projection operation, can be 
compared with slicing methods f 201, as they consists in extracting 
specific parts of a global program. Type systems have been used 
to ensure memory consistency 1191 , or for pointer analysis within a 
distributed architecture [ 12]. The ACUTE language 1 17] is an exten- 
sion of OCAML with typed marshalling. Communication channels 
between two ACUTE programs can also be considered as typed, 
as the type of marshalled and unmarshalled data are dynamically 
verified, at execution time. The consistency considered is between 
separately-built programs, whereas our approach is to consider the 
programming of a distributed system as one global program, al- 
lowing global static verifications. Our approach can be compared 
with automatic partitioning: the J-Orchestra system [ 13] allows the 
user to assign network sites to classes of Java programs. Then, this 
automatic partitioning system transform the initial program into 
a distributed one, taking into account distant or direct references. 
This last approach differs with our by the fact that we integrate 
the distribution constructs within our language, which allows rely- 
ing distribution on semantical basis. Finally, Oz and its distributed 
extension [4| proposes a way to separate the functionality of a dis- 
tributed application and its distribution structure, by allowing the 
programmer to give a different distributed semantics to every differ- 
ent object of a program. These two languages aims at loosely cou- 
pled distributed systems without architecture constraints, whereas 
our approach concerns strongly coupled architecture, and we aim 
to ensure the consistency of the distribution w.r.t. one architecture, 
given the communication constraints. 

5.3 Conclusion and Future Work 

We have proposed a spatial type system to solve the problem of 
automatic distribution of dataflow programs. It is based on a core 
dataflow language, which we have extended with distribution prim- 
itives to allow the programmer to specify, on one hand his/her target 
distributed architecture, and on the other hand where some nodes 
and/or variables are to be located. The underlying philosophy is 
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Figure 7. Rules for the projection operation (II). 



the functional distribution, meaning that some functionalities of 
the program must be computed at some precise location because 
they require some specific sensors, actuators, and/or computing 
resources that are available only at this location. In this context, 
we use type inference to decide at which location each node must 
be computed, and at which points in the program communication 
primitives must be inserted. The compilation of a correctly spatially 
typed program produces one program for each computing location 
specified by the programmer. We use abstract communication chan- 
nels to exchange a value between two locations and to synchronize 
them. Compiling each program and linking with a dedicated library 
implementing those communication channels then gives one binary 
code for each location. The refined version of the type system, as 
well as the operation projection, has been implemented in a syn- 
chronous dataflow compiler (T|. 

Future work mainly involves allowing the description of more 
complex architectures, with hierarchical locations or communica- 
tion masking (e.g., MPSoCs): our proposal of architecture con- 
straints is not sufficient to catch the complexity of actual architec- 
ture of distributed embedded systems. Yet, our current constraints 
show the interest of a type system for checking the consistency of 
a distributed program w.r.t. such constraints. 
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